Skip to content

Create/update an issue per feature #7

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 31 commits into
base: main
Choose a base branch
from
Open

Create/update an issue per feature #7

wants to merge 31 commits into from

Conversation

foolip
Copy link
Collaborator

@foolip foolip commented Jun 13, 2025

No description provided.

@foolip foolip force-pushed the issue-per-feature branch from 956766e to 0b0a11f Compare June 13, 2025 10:14
Co-authored-by: Patrick Brosset <[email protected]>
@foolip foolip marked this pull request as ready for review July 15, 2025 08:38
@foolip
Copy link
Collaborator Author

foolip commented Jul 15, 2025

I think this would work now. @captainbrosset care to review? In particular the issue template is important, and isn't very good yet.

@foolip
Copy link
Collaborator Author

foolip commented Jul 15, 2025

Seeing that it would "only" create ~300 issues I went ahead and triggered this in https://github.com/web-platform-dx/developer-signals/actions/runs/16290425578/job/45998890724 to shake out additional bugs. Issues are being created now.

@foolip
Copy link
Collaborator Author

foolip commented Jul 15, 2025

I got the escaping wrong, deleting some code should fix that...

This should fix < in issue titles
@foolip foolip mentioned this pull request Jul 15, 2025
@foolip
Copy link
Collaborator Author

foolip commented Jul 15, 2025

Detecting open issues doesn't reliably work, debugging...

Update: fixed

@foolip foolip requested a review from captainbrosset July 23, 2025 14:39
await writeFile("manifest.json", manifestJson);
console.log('Wrote manifest.json');

// TODO: close open issues that were skipped / not updated.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this something that should be addressed now or later?

Not sure if it's what you had in mind here, but we should close issues for features that have since graduated to Baseline status, along with a clarifying comment.

On the flip side, if a feature regresses, we should reopen the existing issue to preserve the original upvotes.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this something that should be addressed now or later?

I intended to address it later, and basically just close any issues that we didn't put in the manifest. But I wanted to see which issues would be closed in practice before automating it, to see if the rule feels right. One could imagine a different rule for opening new issues vs. closing old issues, with a grace period of sorts.

On the flip side, if a feature regresses, we should reopen the existing issue to preserve the original upvotes.

This is a good point, and would require iterating closed issues as well. Unfortunately I've already made a mess of things with issues that I opened by accident due to a bug, which would lead to multiple issues found for some features. Maybe I could just edit all of those issues to be blank to avoid the problem.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Making a mess, while working on this script is not a problem. We can always just delete issues and start again.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Deleting the issues would be good to avoid having to deal with them in the future. @tidoust do you have admin rights to delete the 35 issues from #324 through #358? They are currently matched by this search.


For more details on this feature:

${data.caniuse ? `- [caniuse.com](https://caniuse.com/${data.caniuse})` : ""}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are good resources to point to. I would perhaps add a link to MDN too.
We have some mappings for this too at: https://github.com/web-platform-dx/web-features-explorer/blob/main/additional-data/mdn-docs.json

(soon at https://github.com/web-platform-dx/web-features-mappings/blob/main/mappings/mdn-docs.json)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since there can be multiple MDN links for a feature, sometimes it's a list and each item needs a name of some sort. I see that in https://web-platform-dx.github.io/web-features-explorer/features/individual-transforms/ you went from "Web/CSS/transform-function/translate" to "translate()" and it seems like the code for that is here:

https://github.com/web-platform-dx/web-features-explorer/blob/3a8dba6acaaf49ed14393da2d6f50d0d88c18910/.eleventy.js#L180-L183

What do you think about publishing the titles as well so I don't need to have a dependency on @ddbeck/mdn-content-inventory?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. The new separate mappings repo does have the titles already.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, would you be OK with a TODO to add MDN links once web-features-mappings is on NPM?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes.

const ids = Array.from(manifest.keys()).sort();
const manifestJson = JSON.stringify(
Object.fromEntries(ids.map((id) => [id, manifest.get(id)])));
await writeFile("manifest.json", manifestJson);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
await writeFile("manifest.json", manifestJson);
await writeFile("web-features-signals.json", manifestJson);

The word manifest makes me think of extensions, or PWAs. Sorry, can't help it. What do you think of this more descriptive name?

Also, I see that you're ignoring this file in .gitignore. What do we need it for then? If this is for another use case than just creating/updating issues, then I would move the logic to do this to another script.

Related to this, a file like this would definitely be useful for https://github.com/web-platform-dx/web-features-mappings at some point, so I'm pretty keen on having it, but in this case, I wouldn't ignore it from git.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I want to publish this file somewhere, that's the main remaining piece before this can be used on caniuse or MDN. Not sure if it should be published on NPM or as a GitHub release, or maybe GitHub pages, but I don't think it should be in the repo itself as the commit history would be completely dominated by that file.

But anyway, I'll rename it to web-features-signals.json now, that works for me.

await writeFile("manifest.json", manifestJson);
console.log('Wrote manifest.json');

// TODO: close open issues that were skipped / not updated.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Making a mess, while working on this script is not a problem. We can always just delete issues and start again.

}
}

// Sort features by earliest release date in any browser, using subsequent shipping
Copy link

@captainbrosset captainbrosset Jul 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to sort the features exactly? I'm not sure I follow.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not strictly necessary, but I wanted the issue list to be roughly chronological, with older features being created first, similar to what would happen if this script had been running for years already.

Now that the issues are already seeded I could just delete this. WDYT?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants